To protect and/or authenticate information, it is known that a sender can encrypt data. For example, the sender may encrypt an original message of “plaintext” to create “ciphertext,” such as by encrypting the plaintext using an encryption key in accordance with the Data Encryption Standard (DES) defined by American National Standards Institute (ANSI) X3.92 “American National Standard for Data Encryption Algorithm (DEA)” (1981). The sender can then securely transmit the ciphertext to a recipient. The recipient decrypts the ciphertext to re-create the original plaintext (e.g., using a decryption key in accordance with DES).
To increase the security of an encryption process, multiple rounds of encryption may be performed. For example, FIG. 1 is an overview of a sixteen round DES encryption process 100. After an Initial Permutation (IP) is performed on an original 64-bit block of plaintext, the information is divided into a left potion (L0) and a right portion (R0), each being 32 bits long. In the first encryption round, R0 is combined with an encryption key (K1) via a function (ƒ). The output of this function is then combined with L0 via an exclusive OR (XOR) operation. Finally, the result of the XOR operation becomes the right portion for the next encryption round (i.e., R1) and R0 becomes the left portion (i.e., L1). This “swapping” process is repeated in each of the first fifteen encryption rounds, thus:Ri=Li−1XORƒ(Ri−1, K1)Li=Ri−1In last encryption round, the left and right portions are not swapped, thus:Ri=Ri−1(or R16=R15)Li=Li−1XOR ƒ(Ri−1, Ki)(or L16=L15XOR ƒ(R15, K16))
FIG. 2 illustrates one round 200 of the DES encryption process in further detail (round i). In particular, the function ƒ includes an expansion permutation (EXP) 210 that generates a 48-bit value based on the 32-bit right portion (Ri−1). In addition, two 28-bit halves of the current 56-bit encryption key are circularly shifted 230 and combined via a compression permutation (COMP) 240 to generate a 48-bit subkey (Ki). The subkey is then combined with the result of the expansion permutation 210 via an XOR operation 220, and the result of the XOR operation 220 is provided to an S-box substitution unit 300.
As illustrated in FIG. 3, the S-box substitution unit 300 converts a 48-bit input 310 to a 32-bit output 320 via a number of S-boxes. In particular, each S-box translates a six-bit input (b1 through b6) into a four-bit output in accordance with a table of predefined values. FIG. 4 is a table 330 illustrating four rows and sixteen columns of S-box values 332 for the first S-box. Note that b1 and b6 represent the particular row and b2 through b5 represent that particular column that will be used to select the appropriate four-bit S-box output (i.e., “0” through “15”).
Referring again to FIG. 2, the 32-bit output from the S-box unit 300 is scrambled via a P-box permutation unit 250 before being combined with the 32-bit left portion (Li−1) via a second XOR operation 260. Referring again to FIG. 1, the process is repeated sixteen times (with the left and right portions not being swapped in the final round). A final permutation (IP−1) is then performed to generate the ciphertext.
The encryption process is then repeated for the next 64-bit block of plaintext. A process similar to the one described with respect to FIGS. 1 through 4 may be performed to decrypt a ciphertext message (i.e., to re-create the original plaintext).
Thus, a device adapted to protect and/or authenticate information will sometimes need to swap—and sometimes need to not swap—the left and right portions during encryption rounds. Moreover, the device may need to load information associated with a new block of plaintext (or a new block of ciphertext during a decryption process). This type of device, however, may be inefficiently designed given the environment in which it is implemented. For example, a device may be designed for a Field-Programmable Gate Array (FPGA) environment. An FPGA is an integrated circuit that can be programmed after manufacture by connecting various Configurable Logic Blocks (CLBs), such as look-up tables, together in different ways. A design for a device adapted to protect and/or authenticate information might inefficiently use such CLBs, especially if different types of processes need to be supported (e.g., swapping or not swapping left and right portions, or loading a new block of plaintext or ciphertext).